기능 1)

기능 2)

예시) Apache Server, Nginx

WAS = Web Server + Web Container

WAS는 웹 서버와 웹 컨테이너가 합쳐진 형태로서, 웹 서버 단독으로는 처리할 수 없는 데이터베이스의 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공한다. 덕분에 사용자의 다양한 요구에 맞춰 웹 서비스를 제공할 수 있다. WAS는 JSP, Servlet 등 구동환경을 제공해주기 때문에 웹 컨테이너 혹은 서블릿 컨테이너라고도 불린다.

컨테이너는 동적인 데이터들을 처리하여 정적인 페이지로 생성해주는 소프트웨어 모듈 이다. 사용자가 로그인해서 My Page 메뉴에 들어간다고 가정해보겠다. 이 메뉴에서는 각자 사용자에 따라 보여질 정보가 다르다. 사용자의 요청이 들어오면 웹 서버는 정적인 요소만 클라이언트 측에 보낼 수 있고, 동적으로 처리해야 하는 부분은 처리할 수 없다. 컨테이너는 이러한 부분을 대신 처리해서 웹 서버에 정적인 파일로 만들어서 보내주는 모듈이라고 생각하면 될 것 같다.

클라이언트 측에서 크롬 개발자 도구를 이용하여 파일을 살펴보면 php, ejs 파일도 만든 소스코드도 전부 html로 전송된다. 이는 해당 파일에서 처리해야할 부분을 처리하고 정적 파일로 만든 후에 클라이언트에게 보내는 것이다. php 나 js 코드 등으로 처리한 코드 부분도 클라이언트 측에서는 볼 수 없다.

참고) Java 기반 프레임워크 Spring에서의 컨테이너, 그중 서블릿 컨테이너에 대한 설명이다.

Apache는 CGI라는 개념을 지원한다.

참고) Java 기반 프레임워크 Spring에서의 컨테이너, 그중 서블릿 컨테이너에 대한 설명이다.

WAS의 내부 구조

1. 기능을 분리하여 서버 부하 방지

WAS 앞에 웹 서버를 둬서 웹 서버에 정적인 문서만 처리하도록하고, WAS는 애플리케이션의 로직만 수행하도록 기능을 분배해서 서버의 부담을 줄인다. 개발 공부하면서 많이 들어봤을 관심사의 분리를 하는 것이다.

2. 물리적으로 분리하여 보안 강화

3. 여러 대의 WAS를 연결 가능

대용량 웹 어플리케이션의 경우(여러 개의 서버 사용) Web Server와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다. 예를 들어, 앞 단의 Web Server에서 오류가 발생한 WAS를 이용하지 못하도록 한 후 WAS를 재시작함으로써 사용자는 오류를 느끼지 못하고 이용할 수 있다.

4. 여러 웹 어플리케이션 서비스 가능

예를 들어, 하나의 서버에서 PHP Application과 Java Application을 함께 사용하는 경우

Client - MiddleWare Server - DB Server

: 도메인 로직, 어플리케이션 로직

: 프로그램의 핵심 로직

: 어떻게 데이터가 생성되고 저장되고 수정되고 삭제되는지를 정의한 것

: 현실 세상의 문제를 해결하는 코드

예: 은행앱 → 금융 및 은행 업무, 틱톡 → 동영상 촬영, 감상, 댓글 및 공유

⇒ 참고: https://velog.io/@eddy_song/domain-logic

Client -> Web Server -> Web Application Server -> DB

해당 구조의 동작 과정

앞에서 말한대로 정적 컨텐츠를 처리하는 웹 서버에는 Apache가 있고, 동적 컨텐츠를 처리하는 WAS 서버에는 Tomcat이 있다.

근데 왜 Tomcat은 Apache Tomcat이라는 이름으로 많이 사용될까?

그 이유는 2008년에 릴리즈된 Tomcat 5.5 버전부터 정적 컨텐츠를 처리하는 기능이 추가되었는데, 이 기능이 순수 Apache를 사용하는 것에 비해 성능적 차이가 전혀 없으며 Tomcat이 Apache의 기능을 포함하고 있기 때문에 Apache Tomcat이라고 부르고 있다.

구체적으로는 JSP, Servlet, EJB, JDBC 등 기업용 애플리케이션을 개발하고 실행하는 데 필요한 사양들을 명시하고 있다. 이 사양을 각 vendor 사들이 구현하여 판매하면 개발자들은 어느 제품을 사용하더라도 새로 API를 공부하거나 OS에 따라 변경할 필요가 없는 것이다. 이렇게 Java EE의 사양에 따라 만들어진 제품이 바로 우리가 흔히 말하는 WAS(Web Application Server)이다. 대표적으로는 GlassFish, JBoss EAP 등의 제품이 있다.

Java EE 프로젝트가 오라클에서 이클립스 재단으로 이관되며 공식 명칭이 Jakarta EE로 변경되었다.

위 그림을 보면 Java EE 서버가 클라이언트와 통신하는 구조를 알 수 있다. 그중에서도 Jave EE 서버에 있는 Web Container와 EJB Container를 자세히 보겠다.

Web Container는 위에서 말했듯이, 웹 클라이언트의 HTTP 요청을 받을 수 있고 servlet의 생명 주기를 관리하며 jsp, filter 등을 지원한다. Java에서는 HTTP 요청을 servlet을 통해 처리하기 때문에 Servlet Container라고도 부른다. EJB Container가 웹 브라우저 클라이언트가 요청한 비즈니스 로직을 수행하려면 Web Container를 거쳐야 한다.

EJB(Enterprise Java Beans) Container는 Java EE 응용 프로그램의 Enterprise Bean 실행을 관리하며 요청에 대한 비즈니스 로직을 수행한다. 구체적으로는 bean의 생명주기를 관리하며 보안과 transaction 관리, 리소스 풀링 등의 기능을 제공한다.

보통 WAS가 무엇이냐 물으면 동적 컨텐츠를 제공하는 서버이며 그 예로는 톰캣이 있다고 대답한다. 하지만 톰캣은 온전한 WAS라고 할 수 없다. Java EE를 완전히 구현한 것이 WAS인데, 톰캣은 Java EE 중에서도 Web Container만 구현하고 있기 때문이다.

Java EE에서 Web Container를 구현한 것이 Tomcat이다. 따라서 톰캣은 온전한 WAS가 아니며 HTTP 요청을 Servlet을 통해 관리한다.

스프링과 EJB Container의 관계를 설명하려면, 먼저 EJB의 과거에 대해 알아보아야 한다.

처음엔 EJB가 제공하는 다양한 기능들 덕에 EJB가 많이 사용되었다. 하지만 EJB는 실제 사용할 때 불편한 점들이 너무 많았다. EJB를 사용하려면 제공하는 API를 상속 받아야만 했고, 그에 따른 부가적인 코드를 작성해야 하는 등의 불편함이 있었다. 뿐만 아니라 vendor 사마다 EJB를 구현한 내용이 달라 다른 vendor 사의 제품으로의 변경도 어려웠다. 미들웨어 제품에 대한 종속성을 벗어나기 위해 Java EE가 만들어졌는데, 이제는 특정 Jave EE 제품에 종속되어버리게 된 것이다.

이러한 단점때문에 개발자들은 Java EE와 같은 환경과 기술의 종속에서 벗어나 POJO(Plain Old Java Object) 방식 즉, 특정 클래스를 상속하거나 인터페이스를 구현하지 않는 가벼운 객체를 원하게 되었다. 이런 수요로 인해 Java EE를 개선하여 탄생한 것이 스프링입니다.

스프링은 더이상 비싸고 무거운 Java EE 서버를 사용하지 않아도 주요 기능들을 사용할 수 있게 만들었다. 이제 Java EE가 아닌 Tomcat과 같은 가벼운 일반 Servlet Container와 함께 사용할 수 있게 되었다. 스프링이라는 이름도 이전의 EJB 시절을 겨울에 비유하여 새로운 봄이 온다는 의미에서 지어진 것이다.

이렇듯 스프링은 POJO 방식의 프로그래밍을 지향하면서 적용한 기술이나 메서드가 구현하는 코드에 직접 반영되지 않는 비침투적인(non-invasive) 기술을 사용한다. 이 비침투적인 기술을 위한 스프링의 핵심 기능이 바로 IoC/DI(Inversion of Control/Dependency Injection), AOP(Aspect Oriented Programimg), PSA(Portable Service Abstraction)인 것이다.

Uploaded by